Brief Full Advanced Search Search Tips
|  |  | To access the contents, click the chapter and section titles. Visual Basic 6 Programming Blue Book: The Most Complete, Hands-On Resource for Writing Programs with Microsoft Visual Basic 6! (Publisher: The Coriolis Group) Author(s): Peter G. Aitken ISBN: 1576102815 Publication Date: 08/01/98 Search this book:
Previous | Table of Contents | Next
In this declaration, lpEnumFunc is the address of your program’s callback function (which I’ll explain soon), and lParam is a parameter that the API function passes to the callback function when it is called. Note that this is a common feature of API functions that use callbacks—you can pass a parameter to the API function to be passed to the callback function. How this parameter is used (if at all) depends on the needs of the API function and how you write the callback function. The return value of EnumWindows is True if the function was successful, and False otherwise. If the callback procedure in your Visual Basic program was named EnumWinCallBack, you would call the API function as follows:
    retval = EnumWindows(AddressOf EnumWinCallBack, 0)
The callback function must have the proper signature—that is, its parameters and return value must meet the specifications of the API function it is used with. If you think about it for a moment, this makes perfect sense. The callback procedure is going to be called by the API procedure, which is going to pass certain arguments and expect a certain return value. For EnumWindows, the callback procedure header is:
    Function ProcName(hWnd as Long, lParam As Long) As Long
You can see that when the API procedure EnumWindows calls the callback procedure, it will pass two type Long parameters and expect a type Long return value. If the signature of the callback procedure does not exactly match what the API procedure expects, you can find yourself in big trouble. Here’s a brief review of how callbacks work (I know I am repeating some information, but it is important for you to grasp this concept): 1. Your Visual Basic program calls the API procedure. 2. The API procedure performs some processing, then calls the callback procedure in your Visual Basic program. 3. The callback procedure performs the required tasks, then terminates. Execution returns to the API procedure. 4. The API procedure performs additional processing, if required, which may include additional calls to the callback procedure. Note that execution always passes from the callback procedure to the API procedure; execution never passes from the callback procedure directly back to the Visual Basic program. 5. The API procedure terminates, and execution returns to your Visual Basic program. You must observe several rules and cautions when using callbacks. First of all, both the callback procedure and the call to the API procedure must be placed in a Basic module. They cannot be part of a form or class module. The Basic module must be part of the same project, as well. Also, you can use AddressOf only with user-defined functions—not with external functions declared with the Declare statement or with functions referenced from type libraries. There are also some caveats regarding errors. Because the caller of a callback is not within your program, you must be sure that an error in the callback procedure is not propagated back to the caller. You can accomplish this by placing the On Error Resume Next statement at the beginning of the callback procedure. Working with callback functions can be tricky, because you lose the stability of the Visual Basic development environment any time you call a DLL. When working with callbacks, you will find that it is especially easy to cause the application to crash, so save frequently and keep backups. Areas that require special attention when working with callbacks include the following: • Your application can fire a callback function while in break mode. The code will be executed, but any breaks or steps will be ignored. You cannot do a reset in break mode when a callback function is on the stack. • The callback function may be treated by Windows as relocatable code. If you delete a callback function while in break mode, Windows may loose track of its location in memory. This is particularly likely if you delete a callback function in break mode and then retype it. The bottom line? Don’t delete callback functions in break mode. • Pay strict attention to the callback function’s signature. If you pass a callback function that takes a different number of arguments than the caller expects, your application may fail. • You can use AddressOf only to pass a function pointer to a DLL procedure, and not from one part of a Visual Basic program to another. #### A Callback Demonstration One of the important uses for callbacks is for API functions that provide certain kinds of system information. Often, you cannot know the amount of information ahead of time.
Previous | Table of Contents | Next

| Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.